The IP Multimedia Subsystem (IMS) is a Next Generation Networking (NGN) architecture for telecommunications services standardised by the 3rd Generation Partnership Project (3GPP) and fixed services standardised by the ETSI Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN) group. IMS was defined using Internet protocols standardised by the Internet Engineering Task Force (IETF). Specifically, IMS builds on the IETF Session Initiation Protocol (SIP) with a few extensions standardised by 3GPP and running over the Internet Protocol (IP). Both packet-switched and circuit-switched telecommunications systems are supported and any combination of IMS and Internet users can setup a session between them.
IMS was designed not only to provide new services, but also to act as an integration platform for both current and future services, both telecommunications and Internet services. IMS aims to provide access to services to both stationary and mobile users, regardless of the type of network they currently roam. Consequently, IMS merges the Internet with the mobility paradigm for application developers by enabling the use of cellular technologies to provide ubiquitous access and Internet technologies to provide appealing services.
The IMS hosts a plurality of basic communication functions for providing services to subscribers, for example for authentication, charging, storage of user profiles, etc. Value-added services (VAS) may also be provided via IMS. VAS are services which rely on basic services such as the abovementioned standard call services, but which offer additional benefits to the user and may thus also offer possibilities for the service provider to generate revenues. General examples of VAS in the telecommunication area are facsimile services and telephone information services; in the mobile area, SMS and MMS are prominent examples for VAS. Value-added services may be provided by the mobile operator himself, but may also be provided by a third-party VAS provider.
A central node in IMS networks is the S-CSCF (Serving Call State Control Function), which performs session-related functions such as registration, authentication and session control for a user (or, more precisely, for a user identity in the network). The S-CSCF also implements session routing functions for calling and/or called IMS users. A HSS (Home Subscriber Server) node hosts a service profile database for storing user profiles. Generally, in IMS networks the call/session processing logic and the service control logic are separated. Therefore the service control for particular services such as VAS is located in application servers internal or external to the IMS. A service request from a user is forwarded by the S-CSCF, which thus acts as a service routing node, to the corresponding application server.
The SIP (Session Initiation Protocol) may be used for controlling sessions in an IMS network. SIP is used for establishment, control and tearing down of sessions. Invocation of services via SIP may be achieved by using either a public SIP URI (Uniform Resource Identifier) or a private URL (Uniform Resource Locator). An URI only names a resource, e.g. an application server, whereas an URL, which is typically device specific, specifies a resource location in the network and thus allows accessing the resource. Routing of service invocation calls may be handled by a SIP registry, i.e. a CSCF node that is aware of the current locations of every registered user, application server, etc. (i.e. any registered user identity; a server may also be regarded as a user in this respect) and redirects service invocation calls specifying an URI to a currently correct URL.
A user identity is represented in an IMS network by a user agent, which may be located in a user device associated to the user identity or elsewhere in the network. The user agent acts on behalf of the user device, for example registers the device in the network. Invoking a service in an IMS network may comprise reception of a service request originating from a user agent at the S-CSCF. An URI of a service resource may be specified in the service request. The S-CSCF then forwards the service request to the application server hosting the requested service. For this purpose, the S-CSCF has a number of “initial Filter Criteria” implemented, which allow a decision to which application server to forward the received SIP message representing the service request.
The iFC may be generally regarded as service routing rules. These rules basically comprise a filter part and a decision part, wherein the filter part comprises the so-called Service Point Triggers (SPTs) defining one or more filter criteria which are applied to incoming service request messages. The decision part specifies the action(s) to be taken when the incoming message matches with the filter criteria of the rule. The SPTs indicate the points in the session control signalling on which filter criteria can be set. For example, a filter criterion can be set on an initial incoming SIP message such as a REGISTER or INVITE message and/or on the presence or content of one or more header fields in the message. A set filter criterion may then comprise, for example, a specific address (e.g., URI) of an application server. Filter criteria are specific for a user identity and a given application server.
Filter criteria thus basically trigger sending a service-related message such as a service request to a specific application server. Filter criteria used by the S-CSCF for triggering application servers during processing of service requests are specified by the 3GPP (3rd Generation Partnership Project) UMTS standardisation body for example in the TS (Technical Specification) 23.218, TS 23.228 and TS 29.228.
There are two kinds of filter criteria, the initial filter criteria (iFC) and subsequent filter criteria. Initial filter criteria are stored in the HSS as part of the user-related service profile. If the user is subscribed to multiple services, multiple iFCs will be part of its subscriber profile stored in the HSS. Each iFC thus represents a provisioned subscription of a user to an application. The iFCs are received by the S-CSCF from the HSS during registration (e.g., initial registration or renewed registration) of a user identity in the IMS domain. Subsequent filter criteria may be signalled from an application server to the S-CSCF once the server has been involved in service control by the S-CSCF, which performed a routing decision based on the corresponding iFC. The subsequent filter criteria allow the dynamic (re-)definition of the relevant SPTs at application execution time.
For the definition of a new service, corresponding new iFCs have to be generated and provided to the user service profiles in the HSS. Typically, iFCs are created by administrative action. For example, new iFCs may be entered and created at an OAM(Operation, Administration and Maintenance)-terminal by an administrator for a possibly large number of users. After creation, the iFCs are transferred into the HSS and stored in association with the corresponding service profiles. Therefore, after a new service is available on an application server and after provision of the corresponding iFCs in the HSS, for each user a new registration is required to trigger downloading of the new iFC to the S-CSCF. Only after the iFCs are ready to be applied to incoming service-related messages the new service can be provided to the users. These service provisioning procedures are thus expensive and cumbersome in that they require considerable administrative action and a (re-)registration of the users.
The automatic creation of new services plays already today an important role for application service providers and will presumably play an even more important role in the future. However, after a service has been made available to users in the application server in an automated way, still the iFCs have to be generated and downloaded to the service routing nodes. These requirements may even prevent an automatic provisioning of the new service, at least they lead to a considerable overhead for the provisioning. Thus, the new service can be provisioned only with a delay which depends, amongst others, on the employed OAM-resources
There is a need for a technique for providing services in a service provisioning network which enables the provisioning of a new service in a fast and efficient way.